Multi-user multimedia messaging services

ABSTRACT

Methods, devices, and computer programs for improving the efficiency of multi-user multimedia messaging services are disclosed. A multimedia message is sent from an originator user device to an originator server and further to one or more recipient servers to which recipient user devices as addressed are associated to. The one or more recipient servers execute a multicast delivery for distributing the multimedia message to the recipient user devices and/or an improved reporting of a transmission state of the multimedia message by receiving status messages from the recipient user devices, each status message comprising an indication of an individual transmission state of the multi media message at one of the recipient user devices, aggregating the indications into a report representing the transmission state of the multimedia message, and sending the report to the originator server.

TECHNICAL FIELD OF THE INVENTION

The present invention relates to the field of mobile communicationnetworks, especially to a method and devices for optimizing multi-usermultimedia messaging services.

BACKGROUND OF THE INVENTION

Short Message Service (SMS) has been very successful in the GlobalSystem for Mobile communication (GSM) second generation (2G) system,wherein it is possible to execute non realtime text transmission bymeans of GSM terminals, e.g. from an internet computer terminal to amobile phone or from one mobile phone to another. This easy to useservice for non realtime text transmission shall be succeeded to in 2.5Gand third generation (3G) mobile systems by a non real-time MultimediaMessage Service (MMS). With MMS, users are allowed to send and receiveMultimedia Messages (MM) exploiting the whole array of media typesavailable today e.g. text, images, audio, video while also making itpossible to support new content types as they become popular.

A non-realtime MM, or otherwise called store and forward MM, is acombination of one or more different media elements in a multimediapresentation that can be transferred between devices of users withoutthe requirement for the need to be transferred in realtime. Thenon-real-time multimedia messaging service shall be capable ofsupporting current and future multimedia messaging services, and exploitthe advances being made in the world multimedia community, withadditional mobile requirements.

3^(rd) Generation Partnership Project (3GPP) Technical Specification22.140 V4.2.0 (2002-03) and 3GPP Technical Specification 23.140 V4.6.0(2002-03) describe the current state of standardization activities forMMS. For sending a MM from an originator to a recipient, the followingprocedure can be used: A user agent (UA), i.e. an application residingon the originator's User Equipment (UE) or a device attachable to the UEof the originator sends the MM comprising multimedia content and anaddress of the recipient to an originator MMS Relay/Server (R/S). Theoriginator MMS R/S forwards the MM content to a recipient MMS R/S thatsubsequently notifies an UA residing on the UE of the recipient. Thenotification does not contain the MM but a reference to the actual MM.The reception of the MM notice is acknowledged by the recipient MMS UAto the recipient MMS R/S and the MM can then be retrieved by therecipient MMS UA. The retrieval of the MM and the reading of the MM bythe UA of the recipient are acknowledged to the recipient MMS R/S. A MMdelivery report comprising an identification of the original MM, therecipient address, time stamping, and the delivery status can begenerated by the recipient MMS R/S and sent to the originator MMS R/S.The originator MM R/S can send the delivery report to the originator MMSUA, e.g. for indication of the delivery of the MM to the originator MMSUA. A similar procedure is described for sending a read reply reportthat is generated at the recipient MMS R/S when the MM is read by therecipient.

Sending a MM from one originating UA to multiple recipient MMS UAs ispossible. One alternative is to address the MM to multiple recipient MMSUAs and to perform MM replication right at the originating MMS UA.Another alternative is to send the MM and the addresses of the multiplerecipient MMS UAs from the originator MMS UA to the originator MMS R/S.Replication of the MM is executed at the originator MMS R/S even forrecipient MMS UAs that are served by the same recipient MMS R/S. Theprocedure continues as described before for sending the replicated MMsto one or more recipient MMS R/S that subsequently notify the recipientMM UAs for retrieval of the MM. Both procedures are similar to emaildistribution to a number of receivers. Either the entire list ofreceivers is included and multiple emails are send to each of thereceivers or a list-server like majordomo is used. A list servermaintains lists of addresses of users subscribed to one or more groups.Each group can be identified by a group address. An email addressed toone of the groups comprises the corresponding group address on base ofthat and the corresponding list the list-server can retrieve thecorresponding user addresses. A copy of the email is sent to each of thecorresponding user addresses.

The aforementioned procedures are not very efficient. In the case of MMdelivery to multiple recipient MMS UAs, the notification and then therecipient MMS UA triggered retrieval sequence becomes a limitation. Inthe case a large number of recipients UAs gets a notification for thesame MM, the probability is rather high that all or a high fraction ofthe recipient MMS UAs initiate the retrieval of the MM immediately afterthe reception of the notification. In this situation, the recipient MMSR/S sends per recipient MMS UA that requests a retrieval of the MM, amessage for retrieval comprising the MM leading to high load of therecipient MMS R/S and possibly even congestion of the network,especially on the scarce and expensive radio networks between therecipient MMS R/S and the recipient MMS UAs. In addition,acknowledgements of the retrieval or read replies sent from therecipient MMS UAs that have received the MM and read the MM,respectively, initiate the generation of delivery and read-replyreports, respectively, with the number of delivery or read reply reportsamounts to the number of recipients UAs that have received and read theMM, respectively. The reports can be further sent to the originator MMSR/S and to the originator MMS UA leading to congestion of the networkbetween those entities and overload of the entities themselves.

A so-called MM1_submit.REQ message comprising addresses and a MM sentfrom the originator MMS UA to the originator MMS R/S contains flags toindicate whether a delivery report, reply-charging and read reply isrequested. However, these are simple yes/no flags without anygranularity indications on how the originator MMS UA would like toreceive the report. Especially, there is currently no way to control theamount of delivery reports and read reply reports to the originator MMR/S and originator MMS UA triggered by acknowledgements and read-replymessages by the recipient MMS UAs to the recipient MMS R/S. Especiallyin the case of multiple recipients, the amount of acknowledgements andreports and the messaging needed for transmitting the acknowledgementsand reports can lead to a high load of the network entities involvedresulting in overload situations or performance reductions.

SUMMARY OF THE INVENTION

It is an object of the present invention to provide methods, devices andcomputer programs that improve the efficiency of multimedia messageservices with respect to the delivery and/or reports of multimediamessages.

This object is achieved by the method, recipient server, and computerprogram as recited in the claims herein.

A method for efficient transmission of a multimedia message from anoriginator user device to recipient user devices is disclosed. Themethod comprises several steps. In a first step, a first message is sentfrom the originator user device to an originator server. The firstmessage comprises the multimedia message and an indication of addressesof the recipient user devices. Examples for an indication of addressesare a group address of the recipient user devices or a list comprisingthe addresses of the recipient user devices or a combination thereof.

In a second step, an identifying of a recipient server associated to therecipient user devices based on the indication of the addresses isexecuted. This step can include the resolving of a group address. Next,after identifying the recipient server the addressed recipient userdevices are associated to, the first message is sent to the identifiedrecipient server. In a following step, the recipient user devices areidentified on the base of the indication of the addresses, e.g. byresolving a group address into the addresses of the individual recipientuser devices. Furthermore, a multicast delivery of the multimediamessage to the recipient user devices is executed.

The method improves the efficiency of multimedia message services withrespect to the delivery of multimedia messages to recipient user devicesdue to the fact that a multicast delivery of the multimedia message tothe recipient user devices is executed. The transmission of themultimedia message by multicast is advantageous over unicasttransmission, because the messaging and processing effort for thedistribution of the multimedia message to the recipient user devices isreduced. With unicast transmission, the recipient server has to sendeach of the recipient user devices a separate message. According tomulticast, the multimedia message can be send from the recipient serverin a single message which can be replicated close to the recipient userdevices for delivery thus reducing messaging and processing effort ofthe recipient server as well as of possible network entities between therecipient server and the recipient user devices for the multicastdelivery. Further efficiency is gained by the usage of one or more groupaddresses for indication of addresses which is favorable compared to alist of individual addresses especially for a large number of recipientsas group addressing avoids to send many addresses in a message. With oneor more group addresses, the first message can get shorter thus reducingnetwork load and processing effort of the entities handling by the firstmessage.

The multicast delivery can comprise the steps of allocating a multicastaddress, sending the multicast address to the recipient user devices,embedding the multimedia message in an object suitable for a multicasttransmission, preparing by the recipient user devices for a reception ofthe object, joining by the recipient user devices a multicast groupaccording to the multicast address, and sending the object via themulticast transmission to the recipient user devices. The joining stepmay be part of the preparing step or may be executed separately.

According to a preferred embodiment, the execution of the multicastdelivery can be based on the number of recipient user devices, e.g. bychecking a threshold value that when being exceeded by the number ofrecipient user devices triggering the recipient server to proceed with amulticast delivery of the multimedia message.

According to another preferred embodiment, the recipient user devicescan receive in conjunction with the multicast address at least one itemfrom a group comprising a description of an error protection scheme, atime window, a transaction key, charging information, an UniformResource Locator, an Uniform Resource Indicator, a logical name of amulticast group connected to the multicast address, a transmission starttime, and a number of transmissions.

According to another preferred embodiment, at least one of theoriginator server and the recipient server can resolve the addresses ofthe recipient user devices from the indication of addresses. Resolvingthe addresses is necessary in case a group address is used for theindication of addresses. The resolving may be executed by one of theservers or on behalf of the servers at a further entity providing aresolving service.

The recipient user devices can be associated to more than one recipientserver being identified based on the indication of the addresses. Inthis case, the first message can be sent to the more than one recipientserver. Each of the more than one identified recipient servers canidentify its associated recipient user devices, e.g. on the base of theindication of addresses comprised in the first message. Furthermore,each of the identified recipient servers that received the first messagecan execute a multicast delivery of the multimedia message to itsassociated recipient user devices.

A method for efficient reporting of a transmission state of a multimediamessage addressed to recipient user devices is disclosed. The methodcomprises several steps. In a first step, a multimedia message from anoriginator server is received at a recipient server. The recipientserver can identify the recipient user devices to which the multimediamessage is addressed to and which are associated to the recipientserver. In a next step, the multimedia message can be sent from therecipient server to the addressed recipient user devices associated tothe recipient server. Furthermore, the recipient server can receivestatus messages each comprising an indication of an individualtransmission state of the multimedia message at one of the recipientuser devices. Examples for the indications for the individualtransmission state comprise at least one item from a group comprising anacknowledgement of a notification about the multimedia message, anacknowledgement of a delivery of the multimedia message, and anacknowledgement of a reading of the multimedia message. The receivedindications can be aggregated into a report representing thetransmission state of the multimedia message, e.g. a report comprisingdelivery and read acknowledgements received from the recipient userdevices in an aggregated way. Furthermore, the report can be sent to theoriginator server.

The method improves the efficiency of multimedia message services withrespect to the reporting of a transmission state of a multimedia messageaddressed to multiple recipient user devices. The reporting ofinformation in an aggregated way is much more efficient than executing areporting by sending individual messages comprising each an individualtransmission state of an addressed recipient user device. Less messagescan be used for aggregated reporting which results in a lower networkload and reduced processing effort for the recipient server and theoriginator server compared to state of the art solutions. Furthermore,reporting in an aggregated way typically provides a more adequateoverview on the transmission state compared to individual informationwhich can enable a faster analysis of the transmission state.

The multimedia message can be received from an originator user device.The report received by the originator server can be sent to theoriginator user device for reporting to the originator user device thetransmission state of the multimedia message.

According to a preferred embodiment, the indications are compiledaccording to a request. The request can e.g. originate from at least oneentity from a group comprising the originator user device, theoriginator server, and the recipient server. The compiled indicationscan be aggregated according to the invention. The request can bemodifiable or one or more requests can be added to the request, e.g. bythe recipient server and/or the originator server.

According to a preferred embodiment, those of the status messages areused for the report that are received within a time interval. Collectingstatus messages like acknowledgements within a time interval may avoidlong response times for the reporting.

According to another preferred embodiment, one or more of theindications are relatable to one or more addresses of the recipient userdevices and the report comprises the one or more addresses related tothe transmission state. Reporting one or more addresses related to thetransmission state of the multimedia message provides furtherinformation that can be further used, e.g. a recipient user devicehaving not received the multimedia message can be addressed once morefor sending the multimedia message.

According to another preferred embodiment, the report can be processedfor statistical and/or charging purposes.

The recipient user devices can be associated to more than one recipientserver. In this case, the originator server can send the multimediamessage to the more than one recipient server and can receive more thanone report each representing the transmission state of the multimediamessage related to the respective recipient server. For reporting of thetransmission state of the multimedia message, the originator server canaggregate the more than one reports into a further report representingthe transmission state of the multimedia message.

The originator user device can comprise an originator multimedia messageservice user agent. The originator user device may be a user equipmentlike a mobile phone or a server having access to a multimedia messageservice for executing the steps of the method as far as related to theoriginator user device.

The recipient user devices can comprise each a recipient multimediamessage service user agent. Correspondingly, a recipient user device maybe a user equipment like a mobile phone or a server having access to amultimedia message service for executing the steps of the method as faras related to the recipient user device.

The originator server can be an originator multimedia message servicerelay server and/or the recipient server can be a recipient multimediamessage service relay server. The originator server and the one or morerecipient servers can be realized on separate or one or more commonplatforms.

One or more of the steps of the method for efficient transmission of amultimedia message from an originator user device to recipient userdevices and of the method for efficient reporting of information about atransmission state of the multimedia message addressed to the multiplerecipient user devices can be combined. The combination furtherincreases the efficiency as a multimedia message service benefits fromthe reduced messaging and processing effort associated with both, themulticast delivery and improved reporting.

The invention is embodied in devices like a recipient server, anoriginator server, and a originator user device that are explained inmore detail in the following.

A recipient server for efficient transmission of a multimedia message torecipient user devices is disclosed. The recipient server comprises areceiving unit for receiving messages, a transmission unit for sendingmessages, and a processing unit for processing messages and information.The receiving unit is adapted to receive a first message comprising themultimedia message and an indication of addresses of the recipient userdevices. The processing unit is adapted to identify the recipient userdevices based on the indication of the addresses. Furthermore, therecipient server is adapted to execute a multicast delivery of themulticast message to the recipient user devices, wherein the processingunit is adapted to execute an allocation of a multicast address, thetransmission unit is adapted to send the multicast address to therecipient user devices, the processing unit is adapted to embed themultimedia message in an object suitable for a multicast transmission,and the transmission unit is adapted to send the object via themulticast transmission to the recipient user devices.

According to a preferred embodiment, the processing unit of therecipient server can be adapted to base the execution of the multicastdelivery on the number of recipient user devices, e.g. by making anappropriate decision for multicast 30 delivery when the number ofrecipient user devices exceeds a threshold value. The recipient servercan be adapted to send in conjunction with the multicast address atleast one item from a group comprising a description of an errorprotection scheme, a time window, a transaction key, charginginformation, an Uniform Resource Locator, an Uniform Resource Indicator,a logical name of a multicast group connected to the multicast address,a transmission start time, and a number of transmission.

The processing unit of the recipient server can be adapted to resolvethe addresses of the recipient user devices from the indication ofaddresses.

A recipient server for efficient reporting of a transmission state of amultimedia message addressed to recipient user devices is disclosed. Therecipient server comprises a receiving unit for receiving messages, atransmission unit for sending messages, and a processing unit forprocessing messages and information. The receiving unit is adapted toreceive from an originator server the multimedia message. Thetransmission unit is adapted to send the multimedia message to theaddressed recipient user devices associated to the recipient server. Thereceiving unit is adapted to receive status messages each comprising anindication of an individual transmission state of the multimedia messageat one of the recipient user devices. The processing unit is adapted toaggregate the indications into a report representing the transmissionstate of the multimedia message. Furthermore, the transmission unit isadapted to send the report to the originator server.

According to a preferred embodiment of the recipient server, theprocessing unit can be adapted to compile the indications according to arequest originating from at least one entity from a group comprising anoriginator user device, the originator server, and the recipient serverand to aggregate the compiled indications.

The processing unit of the recipient server can be adapted to modify therequest and to compile the indications according to the modifiedrequest. In addition or alternatively, the processing unit may beadapted to add one or more requests and to compile the indicationsaccording to the added one or more requests.

According to another preferred embodiment, the processing unit of therecipient server can be adapted to use those of the status messages forthe report that are received within a time interval.

According to another preferred embodiment, the processing unit of therecipient server can be adapted to relate one or more of the indicationsto one or more addresses of the recipient user devices and to relate theone or more addresses to the transmission state in the report.

According to another preferred embodiment, the processing unit of therecipient server can be adapted to process the report for statisticaland/or charging purposes.

One or more functionalities of the recipient server as disclosed forefficient transmission of a multimedia message from an originator userdevice to recipient user devices and for efficient reporting of atransmission state of a multimedia message addressed to recipient userdevices can be preferably combined thus further increasing theefficiency of the multimedia messaging service due to the fact that therecipient server with combined functionality is adapted to execute amulticast delivery and an improved reporting according to the invention.

An originator server for efficient reporting of a transmission state ofa multimedia message addressed to recipient user devices is disclosed.The originator server comprises a receiving unit for receiving messages,a transmission unit for sending messages, and a processing unit forprocessing messages and information. The transmission unit is adapted tosend the multimedia message to more than one recipient server theaddressed recipient user devices are associated to. The receiving unitis adapted to receive reports from the more than one recipient server.Each of the received reports represents a transmission state of themultimedia message related to the respective recipient server from whichthe respective report is received. The processing unit is adapted toaggregate the received reports into a further report representing thetransmission state of the multimedia message.

The multimedia message can be received from an originator user deviceand the transmission unit of the originator server can be adapted tosend the further report to the originator user device.

The processing unit of the originator server can be adapted to executeat least one item from a group comprising a compilation of the receivedreports according to a request, a modification of a request, and anadding of a request.

The processing unit of the originator server can be preferably adaptedto process at least one of the reports and the further report forstatistical and/or charging purposes.

An originator user device for efficient reporting of a transmissionstate of a multimedia message addressed to recipient user devices isdisclosed. The originator user device comprises a receiving unit forreceiving messages, a transmission unit for sending messages, and aprocessing unit for processing messages and information. The processingunit is adapted to generate a request for a report according to aselection by a user of the originator user device. The request comprisesone or more indicators for a compilation to determine the transmissionstate in an aggregated way according to the one or more indicators forthe compilation. The transmission unit is adapted to send the requestand the multimedia message to an originator server. Furthermore, thereceiving unit is adapted to receive the report from the originatorserver according to the request. The received report comprises thedetermined transmission state, i.e. as compiled according the one ormore indicators in an aggregated way.

The proposed method is embodied also in computer programs to executesteps of the proposed method. The computer programs comprise portions ofsoftware codes in order to implement the method as described. One ormore of the computer programs can be stored on one or more computerreadable media. A computer-readable medium can be a permanent orrewritable memory within a device like a user equipment or a server orcan be located externally. One or more of the computer programs can betransferred to a device for example via a cable or a wireless link as asequence of signals.

A computer program loadable into a processing unit of a recipient serveris disclosed. The computer program comprises code adapted to execute anystep of the method according to any of the claims 1 to 19 as far asrelated to the recipient server.

A computer program loadable into a processing unit of an originatorserver is disclosed. The computer program comprises code adapted toexecute any step of the method according to any of the claims 1 to 19 asfar as related to the originator server.

A computer program for efficient reporting of a transmission state of amultimedia message addressed to recipient user devices is disclosed. Thecomputer program is loadable into a processing unit of an originatoruser device comprising e.g. a originator multimedia message user agent.The computer program comprises code adapted to generate a request for areport according to a selection by a user of the originator user device,the request comprising one or more indicators for a compilation todetermine the transmission state in an aggregated way according to theone or more indicators for the compilation, and comprises code to effecta sending of the request and the multimedia message to an originatorserver, and comprises code adapted to process the report received fromthe originator server according to the request, the received reportcomprising the determined transmission state.

In the following, detailed embodiments of the present invention aredescribed with reference to the figures.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 shows a message flow for MM delivery via multicast;

FIG. 2 shows a message flow for multicast MM delivery to multiplerecipient MMS UAs;

FIG. 3 shows a message flow for a MMS with optimized acknowledgement andreporting;

FIG. 4 shows a simplified system for providing multicast MM delivery;

FIG. 5 shows an exemplary embodiment of a MMS system.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 shows a first embodiment for an optimized MMS using multicasttransmission technology for delivery of a MM. To gain from multicasttransport efficiency, a MM is preferably destined to a large number ofrecipients. There are different mechanisms to identify a MM for largerrecipient groups. The mechanisms are based on group addresses instead ofindividual addresses (e.g. phone number). Examples are emaildistribution lists, majordomo lists, or by a dedicated indication in theMM or a message carrying the MM. Most efficient is any kind of deliveryoptimization, e.g. by using common radio channels, when a number ofrecipients are in the same geographical area.

A group address or group identifier like a name of a group can beincluded into a MM1_Submit.REQ message M100 for indicating a group ofusers associated to multiple recipient MMS R/Ss, to the originator MMSR/S 101 where the MM1_Submit.REQ message M100 is sent from theoriginator MMS UA 100 to the originator MMS R/S 101. In the following,group address and group identifier are used synonymously for indicatinga group. A group address can be entered by a user of the UE with theoriginator MMS UA 100. Thus, using group addressing and sendingmechanisms for multimedia messages renders the method simple andconvenient for the end-user as he is freed from the burden to enter allindividual addresses as according to state of the art MM solutions.Alternatively, the addresses of the multiple recipients may be enteredinto the MM1_Submit.REQ message M100.

The MM1_Submit.REQ message M100 comprises in addition the MM for themultiple recipients. The reception of the MM1_Submit.REQ message M100can be acknowledged by the originator MMS R/S 101 to the originator MMSUA 100, e.g. by MM1_submit.RES message M101. The originator MMS R/S 101identifies the recipient MMS R/S 102 and sends the MM and the groupaddress to the recipient MMS R/S 102 by a MM4_forward.REQ message M102which reception can be acknowledged by the recipient MMS R/S 102 to theoriginator MMS R/S 101 via MM4_forward.RES message M103. In case therecipient MMS R/S 102 cannot handle group MMs, i.e. a MM accompanied bya group address, the originator MMS R/S 101 can resolve the addresses ofthe recipient MMS UAs and forwards the MM and the addresses to therecipient MMS R/S 102 by a MM4_forward.REQ message M102 thus ensuringbackward compatibility. Correspondingly, the reception of theMM4_forward.REQ message M102 can be acknowledged by the recipient MMSR/S 102 to the originator MMS R/S 101 via MM4_forward.RES message M103.If the recipient MMS UAs are served by multiple recipient MMS R/Ss,corresponding MM4_forward.REQ messages and MM4_forward.RES messages toand from, respectively, each of the multiple recipient MMS R/Ss can besent. Preferably, the originator MMS R/S 101 identifies one or morerecipient MMS R/Ss the recipient MMS UAs are associated to from theaddress field of the MM1_Submit.REQ message M100 and sends a copy of theMM and one or more recipient group addresses to each of the one or morerecipient MMS R/Ss.

Each of the one or more recipient MMS R/Ss can resolve its recipientgroup address to the individual addresses of the recipient MMS UAs.There are two alternatives to resolve the individual receiver addresses:A first alternative is, that a group resolution server, which resolvesthe group address or group address to the individual addresses isavailable in the network. Beside the group address associated to the MMan indication may indicate a resolution server to the recipient MMS R/Sfor resolving of the addresses from the group address, e.g. an addressof a majordomo list server which resolves the addresses according to thegroup address and delivers the addresses to the one or more recipientMMS R/Ss. The second alternative is, that the MM or one or more of themessages comprising the MM contains a list of receivers beside the groupaddress. The group address is used to differentiate between differentgroups and to indicate group MMs. This also avoids any additional groupserver. The resolving of addresses at the one or more recipient MMS R/Ssis preferable for large user groups, e.g. 10.000 recipient MMS UAs, thusavoiding the sending of many addresses of the recipient MMS UAs from theoriginator MMS R/S to the one or more recipient MMS R/Ss thus reducingnetwork load due to shorter messages and processing effort at theoriginator and recipient MMS R/Ss.

To offer efficient delivery of the MM to the receiving UAs, theMultimedia Broadcast/Multicast Service (MBMS) multicast mode is used.MBMS is currently standardised in 3GPP and specified in TS 22.146 and TR23.846 (see 3GPP TS 22.146 V5.2.0 (2002-03) and 3GPP TR 23.846 0.3.0(2002-01), respectively). To offer multicast based MMS delivery, therecipient MMS R/S 102 allocates a multicast address. An InternetProtocol (IP) multicast address identifies an entire group ofinterfaces, instead of only one. Internet Group Multicast Protocol(IGMP) (see IETF RFC2236) in case of IPv4 and Multicast ListenerDiscovery (MLD) (see IETF RFC2710) in case of IPv6 is used for the groupmanagement. Efficient transmission of IP datagrams is possible, sinceonly one copy of a packet is sent and the packet is replicated close tothe receivers.

The MM is embedded into an object and is pushed using User DatagramProtocol (UDP) transmission protocol to the recipient MMS UAs. Theprocess of “embedding” is necessary to use a transport protocol forfurther forwarding the MM for multicast data delivery as explained inthe following. This process can include the segmentation of a large MMinto smaller fragments. In addition or alternatively, the process caninclude adding of redundancy for error correction and error detection.This process is very similar to preparing web pages for broadcastdistribution like in Digital Video Broadcasting-Terrestic (DVB-T). Toincrease reliability, a data carousel approach is used for Web-Pagebroadcast in DVB-T and this approach can be similarly applied tomulticast delivery of a MM. A further protocol example suitable formulticast transmission is the Broadcast Trivial File Transfer Protocol(BTFTP).

This object, which contains the MM, is called also sometimes “pushobject” in the following description. All recipient MMS UAs that do notreceive the push object can retrieve the MM from the recipient MMS R/S102 using the procedure according to state of the art as explained inconjunction with FIG. 2 in more detail.

While FIG. 1 shows only one recipient MMS UA 103, FIG. 2 illustrates anextension showing multiple recipient MMS UAs 103,204,20 n,20 m. Relevantsteps of both FIGS. 1 and 2 are therefore described and referenced inparallel. FIG. 2, in addition, discloses an indication of a time scalewhich is subdivided in three main time periods TP1,TP2,TP3. A first,initial period can be given by the transmission of MM1_notification.REQmessages M104,M204,M204 n from the recipient MMS R/S 102 to therecipient MMS UAs 103,204,20 n and the subsequent acknowledgement of thereception of the MM1_notification.REQ M104,M204,M204 n messages byMM1_notification.RES messages M105,M205,M205 n from the recipient MMSUAs 103,204,20 n to the recipient MMS R/S 102.

The multicast address is contained in the MM1_notification.REQ messagesM104,M204,M204 n which are sent from the recipient MMS R/S 102 to therecipient MMS UAs 103,204,20 n. A MM1_notification.REQ message torecipient MMS UA 20 m is not shown in FIG. 2 in the initial time periodTP1. It may happen that not all recipient MMS UAs receive theMM1_notification.REQ messages, e.g. because not all mobile terminals areon-line or the transmission is disturbed. For example according to FIG.2, a mobile terminal carrying the recipient MMS UA 20 m may miss theMM1_notification.REQ message sent to said mobile terminal. The sendingof a MM1_notification.REQ message to a recipient MMS UA may be notexecuted if the UE carrying said recipient MMS UA is offline.

The MM1_notification messages M104, M204, M204 n comprise the MulticastAddress and Port and can be can be enhanced by the following options. Afirst option is the utilization of an error protection scheme. Adescription of one or more error protection schemes may be included intothe MM1_notification messages M104, M204, M204 n. There are differentways to protect a multicast push object against corruption.

Erasure Codes (e.g. Reed-Solomon) wherein Redundancy is added to theactual object, which allows identifying or correcting word errors can beused for example. A word may be also one single bit or a number of bits,e.g. a byte. DigitalFountain [ref: J. W. Byers, M. Luby, M.Mitzenmacher, A. Rege, A Digital Fountain Approach to ReliableDistribution of Bulk Data, in Proc. ACM SIGCOMM'98, September 1998]mechanism also adds redundancy to the original object. Carousels orBroadcast Disks for periodic transmission of the object can be utilized.If a word or fragment is missing, the recipient MMS UA waits for thenext cycle. The number of cycles is limited in this scenario. Alsocombinations of the aforementioned mechanisms may be applied in order tofurther protect the MMS against errors.

In FIG. 2, a second time period TP2 in which the recipient MMS UAs jointhe multicast group, prepare themselves for reception of the MM, receiveand acknowledge the reception of the MM is depicted. Thus, a furtheroption for enhancing the MM1_notification messages is an indication of atime-window like the time period TP2 during which the Push object istransmitted on the multicast channel. The Push object is not transmittedfor an infinite time on the multicast group. The Time-Window is notlimited to a single push-object transmission period, since cyclicrepetitions are possible, e.g. by data carousel or broadcast-disk. Thetime period TP2 as an example for a time window may be indicated by astart time of the transmission and number of times the same MM will bedistributed or by a start and stop time of the transmission.

Furthermore, an MM1_notification message can be enhanced by including atransaction key to protect against eavesdropping. In case such anotification message is transmitted via a unicast bearer, a simplemechanism like an indication of a channel via which the MM is to bedistributed to the recipient MMS UAs and of the start time of thetransmission may be sufficient. The indication may be not but thecontent may be encrypted. The decryption key can be sent via thenotification message, i.e. MM1_notification.REQ messages M104,M204,M204n according to FIG. 2. Optionally, Digital Rights managementinformation, e.g. a rights object, can be distributed in thenotification message or together with the content itself via multicasttransport.

Further examples for the enhancement are charging information, a UniformResource Locator (URL)/Unified Resource Indicator (URI) for anindividual, e.g. more reliable but possibly also more expensive, MMScontent retrieval, and a logical name for the group (connected tomulticast address) in order to have more convenient display for theclients. As an example for a logical name: A typical IP multicastaddress is 224.2.4.3. This group might be used for Grand Prix relatedinformation. A logical name would be “GrandPrix” associated to the IPaddress 224.2.4.3. The transmission channel used for the multicasttransmission is described by the multicast group and thus by themulticast address.

The recipient MMS UAs 103,204,20 n having received theMM1_notification.REQ messages M104,M204,M204 n within the initial timeperiod TP1 join in processes P200,P204,P20 n a multicast group andprepare in processes P200,P204,P20 n for receiving of the push object.The multicast group can be joined based on the multicast addresscomprised in the MM1_notification.REQ message. A recipient MMS UA canjoin the multicast group by sending a message like an IGMP or MLDmessage to an entity like a Gateway GPRS Support Node (GGSN) thatcontrols a bearer like a MBMS bearer suitable for multicast MM delivery.According to the present example, recipient MMS UAs 103,204,20 n sendthe messages MC1,MC2,MC3 being e.g. IGMP or MLD messages to a GGSN (notshown in FIG. 2) to join in processes P200,P204,P20 n the multicastgroup. For preparing of the reception of the push object, e.g. a channelfor receiving the push object can be adjusted. Alternatively or inaddition, an encryption, codec, and/or bitrate can be adapted.Furthermore, memory may be reserved for storing or processing the MM onthe recipients' UEs.

The receipt of the MM1_notification.REQ messages M104,M204,M204 n can beacknowledged to the recipient MMS R/S 102 by MM1_notification.RESmessages M105,M205,M205 n. Via multicast data delivery the push objectis transmitted M206 to the recipient MMS UAs; 103;204;20 n. To increasecorrect reception probability, the push object can be transmittedseveral times using a data carousel as explained before.

The reception of the push object can be acknowledged byMM1_acknowledgement.REQ messages M108,M208,M208 n.

For those recipient MMS UAs that miss the push object or theMM1_notification.REQ messages M104, e.g. due to the fact that the pushwindow was missed or because of a corrupted transmission, or forrecipient MMS UAs that are offline, the normal retrieval procedureaccording to state of the art can be used for retrieval of the MM.According to FIG. 2, the recipient MMS UA 20 m e.g. being offline, canbe notified by a MM1_notification.REQ message M204 m in time period TP3when being reachable again. The MMS UA 20 m can acknowledge thereception of the notification message M204 m by a MM1.notification.RESmessage M205 and can subsequently retrieve the MM from the recipient MMSR/S 102. Alternatively, the multicast delivery may be repeated, which ispreferably done if a larger fraction of the recipient MMS UAs havemissed the initial MM1_notification.REQ messages.

A reporting of the transmission state of multimedia message andacknowledging of reports can be executed as indicated in FIG. 1according to state of the art by MM1_acknowledgement.REQ message M108,MM4_delivery_report.REQ message M109, MM4_delivery_report.RES messageM110, MM1_delivery.report.REQ message M111, MM1_read_reply_recipient.REQmessage M112, MM1_read_reply_report.REQ message M113,MM1_read_reply_report.RES message M114, andMM1_read_reply_originator.REQ message M115 or according to moreefficient reporting using report aggregation as described in more detailin conjunction with FIG. 3.

The described procedure can be applied to a single recipient MMS UA asillustrated in FIG. 1. However, improved efficiency is gained formultiple recipient MMS UAs. The operator of a mobile telecommunicationsystem providing MMS may restrict MM multicast delivery to a number ofrecipient MMS UAs exceeding a threshold value. For a group of recipientMMS UAs that amount to be lower than the threshold value, unicasttransmission of MM can be applied. For a number of recipient MMS UAsexceeding the threshold value, multicast MM transmission is applied forenhanced efficiency.

The transmission of the push object can be executed immediately afterthe transmission of the MM1_notification.REQ messages. Optionally, atrigger event may be used to send the MM to the recipient MMS UAs. Atrigger event like a time may be preferably applied in cases of verylarge groups where it may take a while before all returned theacknowledgement of the notification message, i.e. by sendingMM1_notification.RES messages. The time event may also be used to allowfor different random time generations in the recipient MM UA UEs beforereturning the MM1_notification.RES message back to the recipient MMSR/S. Sending the push object at different times will reduce the load ofthe network especially in the case of a high density of recipient MMSUAs located in the same geographical area, e.g. connected to the sameRadio Network Controller (RNC) or located in the same cell. Therecipient MMS R/S can utilize a timer for taking into account times forthe transmission of the MM1_notification.REQ messages and thepreparation P200 for the reception of the push object by the recipientMMS UAs. The push object may be alternatively sent depending on thereception of MM1_notification.REQ messages. Successfully receivedMM1_notification.REQ messages can be indicated to the recipient MMS R/S102 by the MM1_notificaton.RES messages. The recipient MMS R/S 102 maysend the push object after a threshold value for the number of receivedMM1_notification.RES messages is exceeded. Also, more than one recipientMMS R/S may be involved for MMS multicast delivery to multiple recipientMMS UAs. An example for a system comprising more than one recipient MMSR/S is shown in FIG. 5.

A corresponding principle can be applied to Wireless ApplicationProtocol (WAP) Push. In WAP Push, first a service indication istransmitted e.g. via SMS. The WAP over the air (OTA) specifications [seewww.wapforum.org] defines so called “Service Indications” [see ServiceIndication, Version 31-July-2001, WAP-167-ServiceInd-20010731-a.pdf,available from www.wapforum.org], which contain a short message and anUniversal Resource Identifier (URI) indicating the service. Afterreception, the mobile device may start the service indicated by the URIor postpone it to later, e.g. it can put it into the Push Inboxaccording to a WAP section of newer phones. The invention can be appliedalso to further store and forward solutions, e.g. SMS or ExtendedMessaging Services (EMS).

Parts of the group management or group resolution procedures can beimplemented in a MMS Value Added Service Provider (VASP). A MMS VASP maybe used to indicate to the originator MMS R/S whether a MM is to be sentto a large group or not. The originator MMS R/S may consider thisinformation before distributing the MM.

FIG. 3 shows an example for a MMS with improved acknowledgement andreport handling. A MM can be sent from an originator MMS UA 300 tomultiple recipient MMS UAs either via unicast transmission according tostate of the art or via the proposed MMS multicast delivery mechanismexplained in conjunction with FIGS. 1 and 2. In FIG. 3, a unicastmechanism is depicted. For simplicity, only one recipient MMS R/S 302and one recipient MMS UA 303 are depicted which exemplary stand for oneor more recipient MMS R/Ss and one or more recipient MMS UAs,respectively. For MM to multiple recipient MMS UAs per recipient MMSR/S, the number of messages between the multiple MMS UAs and saidrecipient MMS R/S increases (e.g. messages M304-M308, M312). If multiplerecipient MMS R/S are involved, the number of messages (e.g. messagesM302,M303,M309,M310,M313,M314) between the originator MMS R/S 301 andthe multiple recipient MMS R/S 302 increase with the number of involvedMMS R/Ss. A corresponding increase occurs for processes P302,P303,P305in case of multiple recipient MMS R/Ss.

A mechanism for controlling the delivery, reply charging and/orread-reply reports is provided to the originator MMS R/S 301 and/or therecipient MMS R/S 302 and preferably to the originator MMS UA 300 forindicating what kind and how the originator MMS UA 300 intends toreceive one or more delivery, reply charging and/or read-reply reports.In the following, first the indication from the originator MMS UA 300 tothe originator MMS R/S 301 is described. Then, the processing ofacknowledgements and the aforementioned reports is explained.

In the case of multiple recipients UAs 303, the delivery report,reply-charging and read-reply indicators in the MM1_submit.REQ messageM300 sent from the originator UA 300 to the originator MMS R/S 301 areextended from a simple yes/no or “read”/“deleted without being read”indicator to contain the following granularity as an example.

-   -   Information about individual recipient MMS UA required e.g. by        indicating the addresses or identities of recipient MMS UAs to        the originator MMS UA;    -   Information required which number or percentage of recipient MMS        UAs have received the message within a certain time period;    -   Aggregated reports required;    -   Charging/billing information requested

Also combinations of indicators for requested reports can be used.Preferably, the user of the originator MMS UA can select the type ofrequested report, e.g. by selecting indicators indicating the requestfor an aggregated report supplemented with charging information, andsend this request to the originator MMS R/S, e.g. via MM1_submit_REQmessage M300. The selection may be achieved via an input/output unit.The increased granularity with which the originator MMS UA can indicatethe preferred reception of delivery reports, read-replies andreply-charging provides improved end-user convenience and more efficienttransport solutions.

The originator MMS R/S 301 may send the request as from the originatingMMS UA 300 via the MM4_forward.REQ message M302 to the recipient MMS R/S302. The originator MMS R/S 301 may also modify in process P301 therequest of the originator MMS UA 300 and send the modified request tothe recipient MMS R/S 302. In addition or alternatively, the originatorMMS R/S can add one or more requests, e.g. for own statistical orcharging/billing purposes and send the added requests to the recipientMMS R/S 302. Modified and/or added requests are preferably sent viaMM4_forward.REQ message M302.

Examples of such modified or added requests include:

-   -   Information required which number or percentage of recipients        have received the message within a certain time period.    -   Information about the physical location or the recipient        network. The recipient network and/or physical location can be        used for charging or statistical purposes. Both the actual        distance to the one or more recipient networks or just the fact        whether the recipient MMS R/S or UA is in the same network can        be used for charging and statistical purposes.

The originator MMS R/S 301 can store the indicators and keep track ofthe reports that are returned in the following procedure and can notifythe originator MMS UA 300 as requested. Furthermore, the originator MMSR/S 301 can keep track of the information for its own purposes. Examplesof usage of the information in the originator MMS R/S 301 are newmulti-user charging models where e.g. the charges for the originator MMSUA 300 depend on the number of recipients or the actual distributionspeed. The aforementioned requests for controlling the delivery,reply-charging and/or read-reply reports can be propagated from theoriginator MMS UA 300 via the originator MMS R/S 301 to multiplerecipient MMS R/Ss if recipient MMS UAs are connected to differentrecipient MMS R/Ss as e.g. shown in FIG. 5. In this case, the originatorMMS R/S 301 can resolve the addresses of the recipient MMS UAs anddistribute the recipient MMS UAs per recipient MMS R/S involved.Multiple MM4_forward.REQ messages can be used to send the MM and theaforementioned requests to the recipient MMS R/Ss with oneMM4_forward.REQ message per involved recipient MMS R/S.

Upon reception of the propagated requests, the one or more recipient MMSR/Ss 302 can store information about the type of reporting that has beenrequested to be delivered to the originator MMS R/S 301 and/or theoriginator MMS UA 300. The one or more recipient MMS R/Ss 302 may add byprocess P302 requests or modify by process P302 the received requests,e.g. for own statistical purposes or charging/billing purposes, beforenotifying the one or more recipient MMS UAs 303 on the MM.

Delivery of the MM to a recipient MMS UA 303 can be achieved viaMM1_notification.REQ message M304, the MM1_notification.RES messageM305, the MM1_retriev.REQ message M305, and the MM1_retrieve.RES messageM305 and with corresponding further messages in case the MM is to bedelivered to multiple recipient MMS UAs. The delivery to one or morerecipient MMS UAs may be achieved also via MMS multicast as explained inconjunction with FIGS. 1 and 2 which is e.g. preferably in case of largeuser groups per involved recipient MMS R/S.

Upon reception of the corresponding MM1_acknowledgement.REQ messagesM308 from the recipient MMS UAs 303, the one or more recipient MMS R/S302 can compile by process P303 the information according to the requestfrom the originator MMS R/S 301. In the compilation, theacknowledgements, i.e. M1_acknowledgement.REQ messages M308 from the oneor more recipient MMS UAs 303 can be registered. Further information canbe deducted from the MM delivery process like the amount of recipientMMS UAs 303 from the number of MM1_notification.RES messages. M304received by the one or more recipient MMS R/S 302. From the knowledge ofthe addresses of the recipient MMS UAs 303 it may be analyzed which ofthe notified recipient MMS UAs have received the notification and whichnot. It may also be verified which of the recipient MMS UAs haveacknowledged the reception of the MM and which not. A correspondinganalysis may be accomplished for the one or moreread_reply_recipient.REQ messages M312 that indicate which recipient MMSUAs have read the MM.

In order to avoid that all delivery or read acknowledgements, i.e. theM1_acknowledgement.REQ messages M308 and the read_reply_recipient.REQmessages M312, respectively, received for this MM are reported in singleMM4_delivery_report.REQ messages and MM4_read_reply_report.REQ messagesto the originator MMS R/S 301, the one or more recipient MMS R/S 302 canaggregate the delivery or read acknowledgements into one or a fewdelivery or read-reply reports.

An aggregated report may comprise an amount or a percentage of therecipient MMS UAs that have acknowledged the delivery and/or the readingof the MM. The report may comprise alternatively or in addition, theamount of recipient MMS UAs that have not acknowledged the deliveryand/or the reading. It may be helpful for the originator MMS UA 300 toget an indication of the address of the recipient MMS UAs that have orhave not acknowledged the delivery or reading. Therefore, the addressesof the recipients MMS UAs may be linked to the aggregated information onthe acknowledgements. In order to avoid long report response times, therecipient MMS R/S may collect the acknowledgements within a timeinterval. In this case, acknowledgements are registered and are compiledfor the report if they match the time interval. Acknowledgementsreceived not within this time interval may be discarded or may be usedfor a further report. A timer in or accessible by the recipient MMS R/Scan be used for starting the time interval for the registration ofacknowledgements and for stopping the registration according to the timeinterval. The start of the timer may be triggered by theMM1_notification.REQ messages like one or more messages M304 or messagesM104,204,204 n or by the multicast delivery (messages M106;M206 in FIGS.1 and 2). For an aggregated MMS report, received acknowledgments fordelivery and reading of a MM can be related to the MM by using atransaction identity which can be sent to the recipient MMS UAs in theMM1_notification.REQ message.

An example for an aggregated report comprising information on thedelivery and read acknowledgement can be found in Table A. The reportcomprises an MM identity (MM ID). Furthermore, it specifies the amountof recipient MMS UAs addressed, i.e. the number of recipient MMS UAs theMM is to be delivered to in case of a group like a multicast group, theamount of recipient MMS UAs addressed is the number of the recipient MMSUAs in the group. As an alternative, the amount of recipient MMS UAs canspecify the number of addresses selected by the user of the originatorMMS UA the MM is to be delivered to. The amount of notified recipientMMS UAs can be determined by e.g. counting the number ofMM1_notification.RES messages (e.g. messages M105,M205,M205 n,M305) sentfrom the notified recipient MMS UAs. Alternatively, the number ofMM1_notification.REQ messages (e.g. messages M104,M204,M204 n,M304) tothe recipient MMS UAs can be counted. Similarly, the amount of recipientMMS UAs that received the MM can be determined by counting theMM1_acknowledgement.REQ messages (e.g. messages M108,208,M208 n,M308)from the recipient MMS UAs having received the MM or the correspondingmessages for delivery (e.g. messages M106, M307). The amount ofrecipient MMS UAs that read the MM can be determined by e.g. countingthe number of MM1_read_reply_recipient.REQ messages (e.g. M112,M312)sent from the recipient MMS UAs for confirmation of reading the MM.

TABLE A Example for an aggregated report MM identity MM ID Amount ofrecipient MMS UAs addressed: 10 Amount of notified recipient MMS UAs:  9Amount of recipient MMS UAs received the MM:  8 Amount of recipient MMSUAs read the MM:  7 Addresses of recipient MMS UAs not been notified: 1Address Addresses of recipient UAs not acknowledged 2 Addresses deliveryof MM: Address of recipient UAs not reading the MM 3 Addresses DeliveryTime 10:30 pm Time interval for MM1_acknowledgement.REQ reception 2 minTime interval for MM1_read_reply_recipient.REQ 4 min reception

Using the aforementioned messages sent from the recipient MMS UAs fordetermining the respective amounts has the advantage that acknowledged,i.e. confirmed, information is used for report generation. Countingmessages to the recipient MMS UAs has the advantage that a faster reportgeneration may be achieved and that acknowledgement messages from therecipient MMS UAs may be skipped.

Correlating the individual acknowledgment messages with informationrelated to the addresses of the recipient MMS UAs reveals informationabout the addresses of the recipient MMS UAs that missed thenotification, that do not acknowledge the delivery of the MM, and/orthat do not acknowledge reading of the MM.

Further information as the delivery time, the time interval forMM1_acknowledgement.REQ reception and the MM1_read_reply_recipient.REQreception may be specified indicating to the reader of the report therespective acknowledgement message collection intervals.

TABLE B Example for a compiled and aggregated report received by theoriginator MMS R/S from a first recipient MMS R/S. MMS R/S identity ID1MM identity MM ID Amount of recipient MMS UAs addressed: 10 Address ofrecipient UAs not reading the MM 3 Addresses Delivery Time 10:30 pm

TABLE C Example for a compiled and aggregated report received by theoriginator MMS R/S from a second recipient MMS R/S. MMS R/S identity ID2MM identity MM ID Amount of recipient MMS UAs addressed: 20 Address ofrecipient UAs not reading the MM 5 Addresses Delivery Time 10:30 pm

TABLE D Example for a compiled and aggregated report sent from theoriginator MMS R/S to the originator MMS UA. MM identity MM ID Amount ofrecipient MMS UAs addressed: 30 Address of recipient UAs not reading theMM 8 Addresses Delivery Time 10:30 pm

Information like a network identity may be added to a report for thecase one or more of the recipient MMS R/S are located in a networkdifferent from that of the originator MMS R/S. The one or more recipientMMS R/S sends the aggregated reports to the originator MMS R/S, whichpreferably compiles and further aggregates the received reports before adelivery and/or read report is sent to the originator MMS UA 300. Anexample for a compiling and further aggregation can be found in tablesB, C, and D.

From the tables B, C, and D it can be derived that reports can be moreand more compressed by compiling and aggregation. Furthermore, selectionand/or further processing of information in the reports is possible,e.g. it may not be necessary to provide the user of the originator MMSUA with the identities of the recipients MMS R/Ss involved. Thereforethis information is skipped in the report for the originator MMS UA.

Aggregation of delivery and read-reply reports provides more adequateoverviews of the corresponding status in case of multiple recipients ofthe same MM for both the originator MMS UA and Relay/Server. Theaggregated control mechanisms enable more sophisticated group MMScharging, that can e.g. take the number of destinations that havereceived the MM and/or the number of destinations that have read the MMinto account for the billing of the user that originated the MM sincee.g. the originator and recipient MMS Relay/Server as can be made awareof the number of recipient MMS UAs receiving and/or reading the MM byanalyzing appropriate entries in one or more reports according to theinvention. Charging of the user of originator MMS UA may be executed bya further entity, e.g. a charging server, based on one or more of thereports according to the present invention. The originator MMS UA or theuser of the originator MMS UA may analyze the information provided bythe compiled and aggregated one or more reports according to theinvention in order to e.g. initialize a transmission of the MM to thoseof the one or more UAs that missed, e.g. not received, the MM.

Aggregated reply-charging is a service where operators can distinguishthemselves, since the originator MMS UA may be charged less becausetransmission resources are used efficiently, e.g. due to the reducednumber of messages needed for reporting the reception and/or reading ofMMs. In case of reply-charging the originator MMS UA pays for the replymessage. In case of reply-messages, the recipient MMS R/S and theoriginator MMS R/S can compile these replies into a summaryreply-message. In case e.g. only yes/no or ½ are valid answers, theoriginator or the recipient MMS R/S can compile a group reply messageindicating yes and no or 1 and 2 with the numbers or percentage ofrecipient MMS UAs that have replied accordingly.

According to state of the art, for a delivery of a MM to a number ofrecipient MMS UAs up to the same number of delivery reports and up tothe same number of read replies are possible if all addressed MMS UAsacknowledge the delivery and the reading of the MM. According to thepresent invention, only one report to the originator MMS UA is needed.For the case that the recipient MMS UAs are served by one recipient MMSR/S, only one report is needed from the recipient MMS R/S to theoriginator MMS R/S. If the addressed recipient MMS UAs belong todifferent recipient MMS R/Ss, each recipient MMS R/S can send a reportto the originator MMS R/S thus slightly increasing the number of reportscompared to a case where multiple recipient UAs are served by onerecipient MMS R/S. In any case—independent from the number of recipientMMS UAs or the number of recipient MMS R/S involved, it can be ensuredthat the originator MMS UA receives only one aggregated report.

Owing to the flexibility of the proposed method, the originator MMS UAmay be provided also with more than one report, e.g. the originator isprovided with a first report stating the amount of recipient UAs thathave received the MM within a certain time interval, e.g. severalminutes after delivery of the MM, and later, e.g. after several hoursafter the delivery of the MM, with a second report indicating the amountof users that have read the MM.

An example illustrates the effectiveness of the proposed method: Anoriginator sends a MM to 10.000 recipient UAs distributed to 3 recipientMMS R/S. According to state of the art up to 10.000 delivery reports andup to 10.000 read reports are generated and transferred from therecipient MMS R/Ss to the originator R/S which forwards up to 10.000delivery reports and up to 10.000 read reports to the originator MMS UA.In total up to 40.000 report messages are sent. In addition, theacknowledgement messages for acknowledging the reception of theMM4_delivery_report.REQ messages and the MM4_read_reply_report.REQmessages, i.e. the MM4_delivery_report.RES messages and theMM4_read_reply report.RES messages, respectively, amount up to 10.000for each type of acknowledgement message. In total, 60.000 messages haveto be generated, transferred and processed by the entities involvedaccording to the procedure described in 3GPP Technical Specification23.140 V4.6.0 (2002-03). With the proposed method according to thepresent invention, at minimum 3 reports comprising delivery and readinformation from the recipient MMS R/S to the originator MMS R/S areneeded and only one report to the originator MMS UA. In total, only 4reports are needed. Adding 3 messages for acknowledging the reception ofthe reports, i.e. 3 acknowledgment messages sent from the originator MMSR/S to the 3 recipient MMS R/Ss, the total amount of messages is 7 andis thus much lower compared to 60.000 messages according to state of theart solution.

The number of messages needed according to prior art and the proposedinvention for an arbitrary number of recipient MMS UAs and an arbitrarynumber of recipient MMS R/Ss can be calculated as followed:

Number of recipient MMS UAs: N Number of recipient MMS R/S serving the MN recipient MMS UAs: Maximum number of messages according to prior art:6 × N Minimum number of messages according to invention: 2 × M + 1

For calculating the maximum number of messages according to prior art,it has been assumed that all addressed recipient MMS UAs haveacknowledged the delivery and reading. Only messagesMM4_delivery_report.REQ, MM4_delivery_report.RES,MM1_delivery_report.REQ, MM4_read_reply_report.REQ,MM4_read_reply_report.RES, and MM1_read_reply_originator.REQ have beenconsidered for the calculation according to prior art.

For calculating the minimum number of messages according to theinvention it has been assumed that delivery and read reply informationare aggregated in one report, i.e. information comprised in messagesM309 and M313 are merged into one report thus also combining messagesM310 and M314. In addition, message M311 and M315 are merged forcalculating the minimum number of messages according to the presentinvention. However, the combination of different reports ensures animproved effectiveness even in the case that only one recipient MMS UAis addressed. In any case, with the present invention the number ofreports for delivery and reading can be decoupled from the number ofrecipient MMS UAs.

FIG. 4 illustrates multicast MM delivery with exemplary devices andconnections between the devices. A MM is sent from a first entity N400via a service network N401, a core network N402, and a radio accessnetwork N403 efficiently via a shared channel to multiple recipient UAsN410,N420,N430, here depicted as mobile phones and smart phones. Thefirst entity N400 can be an originator MMS UA, an originator MMS R/S, ora recipient MMS R/S. Using a single group address rather than multipledestination addresses enables an efficient and effective utilizationespecially of the scarce radio interface resources.

FIG. 5 shows an exemplary embodiment of a MMS system for executing theproposed invention with multiple recipient MMS UAs D02-D08 served bymultiple recipient MMS R/Ss. S20,S30,S40. When the network elements areunder the control of a single administration, sometimes the expressionMMS environment (MMSE) is used for a MMS system, e.g. as indicated bythe MMSE E100-E400. According to the present example, the multiplerecipient MMS UAs D02-D08 are attached to the recipient MMS R/SS20,S30,S40 by radio access networks RA02;RA03;RA04. A MM can be sentfrom an originator MMS UA D01 via a first radio network RA01 to anoriginator MMS R/S S10. Preferred reports may be indicated by theoriginator MMS UA D01 to the originator MMS R/S S10. The MM can bedistributed to the recipient MMS R/Ss S20-S40 and can be delivered viamulticast to the recipient MMS UAs D02-D08. According to the invention,preferably multicast transmission is used for MM delivery. However, alsoa unicast transmission is possible, e.g. in case one or more of thecomponents involved in the MM delivery is not capable of multicast or ifthe number of the recipient MMS UA per recipient MMS R/S is below acertain threshold number. Also a combination of multicast and unicastdelivery is possible, e.g. multicast delivery for recipient MMS UAsD02-D07 and unicast delivery for recipient MMS UA D08.

Acknowledgements like MM1_acknowledgement.REQ andMM1_read_reply_recipient.REQ messages from the recipient MMS UAs D02-D08are compiled and aggregated into reports by the recipient MMS R/SsS20,S30,S40 and transmitted to the originator MMS R/S S10 thatpreferably further compiles and aggregates the reports from therecipient MMS R/S S20,S30,S40. Finally, a report on the MM can be sentto the originator MMS UA D01 according to the preferences of the user ofthe originator MMS UAs D01 or of the operator providing the MMS.Preferences by the operator can be set by using modify and addfunctionality.

In summary, both the operator of a telecommunication network providingMMS as well as the user of a MMS benefit from the enhanced efficiency ofthe proposed invention: High processing load of a recipient MMS R/S andhuge messaging effort especially costly in a radio network can beminimized due to efficient multicast delivery and compilation andaggregation of reports. These kind of savings on network resources candirectly decrease the cost for MMS helping to make MMS even morepopular. Another important aspect is that aggregated reports aretypically more user-friendly than the way of reporting by singlemessages as it is in state of the art. The invention can be adapted tobe used in 2G, 2.5G, and 3G telecommunication systems e.g. according tothe General Packet Radio Service (GPRS) and the Universal MobileTelecommunication System (UMTS) standard.

The foregoing embodiments and the following glossary are to beconsidered illustrative, rather than restrictive of the invention, andthose modifications which come within the meaning and range ofequivalence of the claims are to be included therein.

Glossary Entities: Originator MMS UA 100, 300, D01 Originator MMS R/S101, 301, S10 Recipient MMS R/S 102, 302, S20, S30, S40 Recipient MMS UA103, 204, 20n, 20m, D02–D08 Messages: MM1_submit.REQ message M100, M300MM1_submit.RES message M101, M301 MM4_forward.REQ message M102, M302MM4_forward.RES message M103, M303 MM1_notification.REQ message M104,M204, M204n, M204m, M304 MM1_notification.RES message M105, M205, M205n,M205m, M305 Multicast Data Delivery message M106 IGMP or MLD messageMC1, MC2, MC3 MM1_retrieve.REQ message M306 MM1_retrieve.RES messageM307 MM1_acknowledgement.REQ message M108, 208, 208n, M308MM4_delivery_report.REQ message M109, M309 MM4_delivery_report.RESmessage M110, M310 MM1_delivery.report.REQ M111, M311MM1_read_reply_recipient.REQ M112, M312 MM1_read_reply_report.REQ M113,M313 MM1_read_reply_report.RES M114, M314 MM1_read_reply_originator.REQM115, M315

1. A method for efficient multicast transmission of a multimedia messagefrom an originator user device to recipient user devices, the methodcomprising the steps of: sending a first message from the originatoruser device to an originator server, the first message comprising themultimedia message and an indication of addresses of the recipient userdevices; identifying a recipient server associated to the recipient userdevices based on the indication of the addresses; sending the firstmessage to the recipient server; identifying the recipient user devicesbased on the indication of the addresses; and executing a multicastdelivery of the multimedia message to the recipient user devices onlywhen the number of recipient user devices exceeds a predeterminedthreshold, wherein, on execution, said multicast deliver is carried outby performing the following: allocating a multicast address, sending themulticast address to the recipient user devices, embedding themultimedia message in an object suitable for a multicast transmission,preparing, by the recipient user devices, for a reception of the objectby performing at least one of the following: adapting an encryptioncodec, adapting a bitrate, and reserving memory for storing orprocessing the multimedia message on the recipient user devices,joining, by the recipient user devices, multicast group according to themulticast address, and sending the object via the multicast transmissionto the recipient user devices.
 2. The method according to claim 1,wherein the recipient user devices receive, in conjunction with themulticast address, at least one item from a group comprising: adescription of an error protection scheme, a time window, a transactionkey, charging information, an Uniform Resource Locator, an UniformResource Indicator, a logical name of a multicast group connected to themulticast address, a transmission start time, and a number oftransmissions.
 3. The method according to claim 1, wherein at least oneof the originator server and the recipient server resolves the addressesof the recipient user devices from the indication of addresses.
 4. Themethod according to claim 1, further comprising the steps of: receivingfrom the originator server the multimedia message at the recipientserver; sending the multimedia message to the addressed recipient userdevices associated with the recipient server; receiving status messages,each comprising an indication of an individual transmission state of themultimedia message at corresponding one of the recipient user devices;aggregating all indications from the received status messages into areport representing the transmission state of the multimedia message;and sending the report to the originator server.
 5. The method accordingto claim 4, wherein at least one of the indications for the individualtransmission state comprises at least one item from a group comprising:an acknowledgement of a notification about the multimedia message, anacknowledgment of a delivery of the multimedia message, and anacknowledgment of a reading of the multimedia message.
 6. The methodaccording to claim 5, the indications being compiled according to arequest originating from at least one entity from a group comprising:the originator user device, the originator server, and the recipientserver; and wherein the compiled indications are aggregated.
 7. Themethod according to claim 5, wherein the originator server receives themultimedia message from the originator user device.
 8. The methodaccording to claim 7, wherein the indications are complied according toa request originating from at least one entity from a group comprisingthe originator user device, the originator server, and the recipientserver, and wherein the compiled indications are aggregated; and therequest is modifiable or one or more requests are addable to therequest.
 9. The method according to claim 5, wherein those of the statusmessages that are received within a time interval are used for thereport.
 10. The method according to claim 5, wherein one or more of theindications are relatable to one or more addresses of the recipient userdevices and the report comprises the one or more addresses related tothe transmission state.
 11. The method according to claim 5, wherein thereport is processed for statistical and/or charging purposes.
 12. Themethod according to claim 5, wherein the recipient user devices areassociated to more than one recipient server and the originator serversends the multimedia message to the more than one recipient server andreceives more than one report each representing the transmission stateof the multimedia message related to the respective recipient server,and the originator server aggregates the more than one reports into afurther report representing the transmission state of the multimediamessage.
 13. The method according to claim 12, wherein the originatoruser device comprises an originator multimedia message service useragent.
 14. The method according to claim 12, wherein the recipient userdevices each comprises a recipient multimedia message service useragent.
 15. The method according to claim 12, wherein the originatorserver is an originator multimedia message service relay server.
 16. Themethod according to claim 12, wherein the recipient server is arecipient multimedia message service relay server.
 17. A recipientserver for efficient multicast transmission of a multimedia message froman originator user device to recipient user devices, the recipientserver comprising: a receiving unit for receiving messages; atransmission unit for sending messages; and a processing unit forprocessing messages and information, wherein the recipient server isadapted to perform the following. receive a first message from theoriginator user device comprising: the multimedia message, and anindication of addresses of the recipient user devices; identify therecipient user devices based on the indication of the addresses; andexecute a multicast delivery of the multicast message to the recipientuser devices only when the number of recipient user devices exceeds apredetermined threshold, wherein, upon execution of said multicastdelivery, the recipient server is further adapted to perform thefollowing: allocate a multicast address, embed the multimedia message inan object suitable for a multicast transmission, send the multicastaddress in a notification message to the recipient user devices toenable the recipient user devices to join a multicast group and preparefor a reception of the object by performing at least one of thefollowing: adapting an encryption codec, adapting a bitrate, andreserving memory for storing or processing the multimedia message on therecipient user devices, and send the object via the multicasttransmission to the recipient user devices.
 18. The recipient serveraccording to claim 17, wherein the recipient server is adapted to send,in conjunction with the multicast address, at least one item from agroup comprising: a description of an error protection scheme, a timewindow, a transaction key, charging information, an Uniform ResourceLocator, an Uniform Resource indicator, a logical name of a multicastgroup connected to the multicast address, a transmission start time, anda number of transmissions.
 19. The recipient server according to claim17, wherein the recipient server is adapted to resolve the addresses ofthe recipient user devices from the indication of addresses.
 20. Therecipient server according to claim 17, wherein the recipient server isfurther adapted to perform the following: receive status messages, eachcomprising an indication of an individual transmission state of themultimedia message at corresponding one of the recipient user devices;aggregate all indications from received status messages into a reportrepresenting the transmission state of the multimedia message; and sendthe report to the originator server.
 21. The recipient server accordingto claim 20, wherein the recipient server is adapted to compile theindications according to a request originating from at least one entityfrom a group comprising an originator user device, the originatorserver, and the recipient server, and to aggregate the compiledindications.
 22. The recipient server according to claim 20, wherein therecipient server is adapted to modify the request and to compile theindications according to the modified request or to add one or morerequests and to compile the indications according to the added one ormore requests.
 23. The recipient server according to claim 20, whereinthe recipient server is adapted to use those of the status messages forthe report that are received within a time interval.
 24. The recipientserver according to claim 20, wherein the recipient server is adapted torelate one or more of the indications to one or more addresses of therecipient user devices and to relate the one or more addresses to thetransmission state in the report.
 25. The recipient server according toclaim 20, wherein the recipient server is adapted to process the reportfor statistical and/or charging purposes.
 26. The recipient serveraccording to claim 20, wherein the recipient server is a recipientmultimedia message service relay server.
 27. A computer program embodiedon a non-transitory computer readable medium of a processing unit of arecipient server, wherein the computer program, upon being executed bythe processing unit, causes the processing unit to perform thefollowing: process a received first message comprising a multimediamessage from an originator user device and an indication of addresses ofthe recipient user devices; identify the recipient user devices based onthe indication of the addresses; execute a multicast delivery of themultimedia message to the recipient user devices only when the number ofrecipient user devices exceeds a predetermined threshold, wherein theprocessing unit executes said multicast delivery by: allocating amulticast address, embedding the multimedia message in an objectsuitable for a multicast transmission, sending the multicast address ina notification message to the recipient user devices to enable therecipient user devices to join a multicast group prepare for a receptionof the object by performing at least one of the following: adapting anencryption codec, adapting a bitrate, and reserving memory for storingor processing the multimedia message on the recipient user devices, andsending the object via the multicast transmission to the recipient userdevices.
 28. The computer program according to claim 27, which, uponbeing executed by the processing unit, causes the processing unit tofurther perform the following: send, in conjunction with the multicastaddress, at least one item from a group comprising: a description of anerror protection scheme, a time window, a transaction key, charginginformation, a Uniform Resource Locator, a Uniform Resource Indicator, alogical name of a multicast group connected to the multicast address, atransmission start time, and a number of transmissions.
 29. The computerprogram according to claim 27, which, upon being executed by theprocessing unit causes the processing unit to resolve the addresses ofthe recipient user devices from the indication of addresses.
 30. Thecomputer program according to claim 27, which, upon being executed bythe processing unit, causes the processing unit to efficiently report atransmission state of the multimedia message addressed to the recipientuser devices by: processing received status messages, each comprising anindication of an individual transmission state of the multimedia messageat corresponding one of the recipient user devices; aggregating allindications from the received status messages into a report representingthe transmission state of the multimedia message; and sending the reportto the originator server.
 31. The computer program according to claim30, which, upon being executed by the processing unit, causes theprocessing unit to compile the indications according to a requestoriginating from at least one entity from a group comprising theoriginator user device, the originator server, and the recipient server,and to aggregate the compiled indications.
 32. The computer programaccording to claim 30, which, upon being executed by the processingunit, causes the processing unit to modify the request and to compilethe indications according to the modified request or to add one or morerequests and to compile the indications according to the added one ormore requests.